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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The present document defines the coding of information in an extension of the Base Station System AppHcation Part 
(BSSAP) that is needed to support location services on interfaces based on use of BSSAP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies procedures and information coding that are needed to define and support the BSSAP 
LCS Extension (BSSAP-LE). The BSSAP-LE message set is appHcable to the following GSM interfaces defined in 
3GPPTS 03.71: 

Lb interface (BSC-SMLC). 

Ls interface (MSC-SMLC). 

Lp interface (SMLC-SMLC). 

The present document defines message formats and encoding for BSSAP-LE and the particular subsets of it that are 
applicable to each of the above interfaces. The present document also defines the support for BSSAP-LE message 
transfer on each of these interfaces using CCITT and ANSI versions of SS7 MTP and SCCP. Additional requirements 
for the above interfaces that are applicable to BSSAP-LE are also defined - e.g. usage of BSSAP (as defined in 
3GPP TS 04.08 and 08.08) on the Lb interface. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 



• 



• 



For a specific reference, subsequent revisions do not apply. 
For a non-specific reference, the latest version applies. 



[1] 3GPP TS 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 

acronyms". 

[la] 3GPP TS 03.32: "Digital cellular telecommunications system (Phase 2+); Universal Geographical 

Area Description (GAD)". 

[2] 3GPP TS 03.71: "Digital cellular telecommunications system (Phase 2+); Location Services 

(LCS); (Functional description) - Stage 2" 

[3] 3GPP TS 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 

layer 3 specification". 

[4] 3GPP TS 04.31: "Digital cellular telecommunications system (Phase 2+); Location Services 

(LCS); Mobile Station (MS) - Serving Mobile Location Center (SMLC); Radio Resource LCS 
Protocol (RRLP)." 

[5] 3GPP TS 04.71: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 

layer 3 Location Services (LCS) specification". 

[6] 3GPP TS 08.06: " Digital cellular telecommunications system (Phase 2+); Signaling transport 

specification mechanism for the Base Station Subsystem - Mobile-services Switching Centre 
(BSS - MSC) interface". 

[7] 3GPP TS 08.08: " Digital cellular telecommunications system (Phase 2+); Mobile-services 

Switching Centre - Base Station System (MSC-BSS) interface; Layer 3 specification" 

[8] 3GPP TS 08.31: "Digital cellular telecommunications system (Phase 2+); Location Services 

(LCS); Serving Mobile Location Center (SMLC) - Serving Mobile Location Center (SMLC); 
SMLC Peer Protocol (SMLCPP)." 
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[9] 3GPP TS 08.71: "Digital cellular telecommunications system (Phase 2+); Location Services 

(LCS); Serving Mobile Location Center - Base Station Subsystem (SMLC-BSS) interface Layer 3 
specification." 

[10] 3GPP TS 09.02: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part 

(MAP) specification". 

[11] CCITT Recommendation Q.702: "Specifications of Signalling System No. 7 - Signalling data 

Hnk". 

[12] CCITT Recommendation Q.703: "Signalling link". 

[13] CCITT Recommendation Q.704: "Signalling network functions and messages". 

[14] CCITT Recommendation Q.707: "Specifications of Signalling System No. 7 - Testing and 

maintenance". 

[15] CCITT Recommendation Q.71 1: "Functional description of the signalling connection control 

part". 

[16] CCITT Recommendation Q.712: "Definition and function of SCCP messages". 

[17] CCITT Recommendation Q.713: "SCCP formats and codes". 

[18] CCITT Recommendation Q.714: "Signalling connection control part procedures". 

[19] ANSI Tl.l 1 1-1996 - Signalling System Number 7 (SS7) - Message Transfer Part (MTP) 

[20] ANSI Tl.l 12-1996 - SignalUng System Number 7 (SS7) - SignalUng Connection Control Part 

(SCCP). 

[2 1 ] TIA/EIA/IS-J-STD-036 - Enhanced Wireless 9-1-1 Phase II, August 2000. 



3 Definitions, abbreviations and symbols 

Unless listed below, all definitions, symbols and abbreviations used in the present document are listed in 
3GPP TS 01.04 and 3GPP TS 03.71. 



Definition of BSSAP-LE 



BSSAP-LE is an extension to BSSAP that contains messages and parameters specific to the support of LCS. The 
following subsets of BSSAP-LE are defined: DTAP-LE, BSSMAP-LE. 



4.1 DTAP-LE Messages 



DTAP-LE messages are transfered between an SMLC and a Type A LMU and comprise the following individual 

messages: 

REGISTER 
FACILITY 
RELEASE COMPLETE 

The content, encoding and certain procedures asssociated with DTAP-LE messages are defined in 3GPP TS 04.71. 
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4.2 BSSMAP-LE Messages 



BSSMAP-LE messages are transferred between a BSC, MSC and SMLC and comprise the following individual 

messages: 

BSSMAP-LE Positioning Messages 

Perform Location Request 

Perform Location Response 

Perform Location Abort 
BSSMAP-LE LMU Control Messages 

LMU Connection Request 

LMU Connection Accept 

LMU Connection Reject 

LMU Connection Release 
BSSMAP-LE Information Messages 

Connection Oriented Information 

Connectionless Information 
BSSMAP-LE General Messages 

Reset 

Reset Acknowledge 
The content and encoding of BSSMAP-LE messages are defined in this specification. 

5 Procedures applicable to use of BSSAP-LE 



5.1 Location Request 



The Location Request procedure is applicable to the Lb and Ls interfaces. Its purpose is to obtain a location estimate for 
a target MS that is already in dedicated mode. It is also used to provide an MS with LCS assistance data or with a 
deciphering key for LCS broadcast assistance data. The initiator of a location request may be either the serving BSC or 
the visited MSC for the MS. The procedure makes use of SCCP connection oriented signaling on the Lb and Ls 
interfaces. 
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5.1.1 Successful Operation 



The initiator of the location request (VMSC or serving BSC) sends a BSSMAP-LE Perform Location Request to the 
SMLC associated with the current serving cell for the target MS. The message contains the following mandatory (M), 
conditional (C) and optional (O) information, where conditional parameters are required if available. 

Location Type (M) 

Cell Identifier (M) 

Classmark Information Type 3 (C) 

LCS Client Type (C) 

Chosen Channel (C) 

LCS Priority (C) 

LCS QoS (C) 

Requested GPS Assistance Data (C) 

BSSLAP APDU (C) 

If requested, the SMLC performs positioning of the target MS using a particular position method or a combination of 
more than one positioning method. If the Classmark Information Type 3 IE is not present, the SMLC shall instigate only 
network based positioning methods (e.g. TOA or TA but not GPS or E-OTD). Alternatively, if requested otherwise, the 
SMLC may provide positioning assistance data to the MS. The SMLC may invoke the following other BSSAP-LE 
procedures to perform these procedures: 

connection oriented information transfer 

connectionless information transfer 

LMU connection establishment 

LMU connection release 

DTAP-LE information transfer 

For an SMLC accessed over the Lb interface by a BSC initiator, additional procedures defined in 3GPP TS 04.08 and 
3GPP TS 08.08 may also be performed. If a location estimate was requested and was subsequently obtained, the SMLC 
shall return a BSSMAP-LE Perform Location Response to the initiator of the location request (serving BSC or VMSC). 
This message contains the following mandatory, conditional and optional parameters. 

Location Estimate (M) 

Positioning Data (C) 

Restrictions on the geographic shape encoded within the Location Estimate parameter may exist for certain LCS client 
types. The SMLC shall comply with any restrictions defined in GSM and, in a particular country, with any restrictions 
defined for a specific LCS client type in relevant national standards. For example, in the US, national interim standard 
TIA/EIA/IS-J-STD-036 restricts the geographic shape for an emergency services LCS client to minimally either an 
"ellipsoid point" or an "ellipsoid point with uncertainty circle and confidence" as defined in 3GPP TS 03.32. 

If assistance data was instead requested for an MS and the SMLC was able successfully to transfer this to the MS, the 
SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location request (serving BSC or 
VMSC). This message shall contain no parameters. The absence of an LCS Cause parameter in this case implies that 
the transfer was successful. 

Otherwise, if a deciphering key was requested for LCS broadcast assistance data and the SMLC has access to the 
appropriate keys, the SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location 
request (serving BSC or VMSC). This message contains the following mandatory parameters. 

Deciphering Keys (M) 
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5.1.2 Unsuccessful Operation 



If the SMLC is unable to obtain any of the location information requested or if requested LCS assistance data could not 
be transferred or requested deciphering keys for broadcast assistance data could not be returned, the SMLC shall return 
a BSSMAP-LE Perform Location Response to the initiator of the Location Request carrying the following parameters: 

LCS Cause (M) 

Positioning Data (O) 

If assistance data or deciphering keys for a specific positioning method is not supported in the network or in the location 
area, the SMLC shall indicate this with LCS Cause value "Position method failure" accompanied with diagnostic value 
"Position Method Not Available in Network" or "Position Method Not Available in Location Area". 

5.1.3 Abnormal Conditions 

If an ongoing location request is preempted at the initiator by an inter-BSC handover or if the main signaling link to the 
target MS is lost or released or if there is a timeout waiting for the positioning response, the initiator shall send a 
BSSMAP-LE Perform Location Abort to the SMLC containing the following parameters. 

LCS Cause (M) 

On receipt of this message, the SMLC shall stop positioning of the target MS and may release any resources (e.g. 
LMUs) previously allocated. If the SMLC has not yet returned a BSSMAP-LE Perform Location Response to the 
initiator, it shall return this message containing an LCS Cause indicating an abort and, optionally, positioning data. The 
initiator shall then release the SCCP connection. If the SMLC cannot proceed with positioning due to some protocol 
violation or error condition (e.g. inter-BSC handover indication received from the serving BSC), it shall return a 
BSSMAP-LE Perform Location Response to the initiator containing an LCS cause and, optionally, positioning data. 
The initiator need not reply at the BSS AP-LE level to this message. However, the initiator may return a BSSMAP-LE 
perform Location Abort which shall not be treated as an error by the SMLC. 

5.1.4 Overload 

If the SMLC is in an overload condition, it may reject a BSSMAP-LE Perform Location request by returning a 
BSSMAP-LE Perform Location response containing an LCS Cause parameter indicating congestion. The initiator of the 
location service request (MSC or BSC) may reduce the frequency of future location service requests until rejection due 
to overload has ceased. In reducing the frequency of location service requests, an MSC or BSC shall reduce lower 
priority requests, to zero if necessary, before reducing the frequency of higher priority requests. An SMLC shall 
similarly reject location service requests of a lower priority, to zero if necessary, due to overload before rejecting 
location service requests of a higher priority. An SMLC in an overload condition may optionally employ the following 
procedures to alleviate overload: 

a) Allow higher priority location service requests to preempt lower priority requests for which location service 
procedures are already in progress 

b) Abort lower priority location service requests already in progress. 

c) Reduce the supported QoS for lower priority requests for a location estimate - e.g. by reducing accuracy or 
increasing response time 

d) Employ MS based positioning methods, where supported by the target MS and SMLC, rather than MS assisted 
or network based methods (except TA). 

The priority of a location service request shall be defined according to the value in the LCS Priority parameter. If this 
parameter is absent in a BSSMAP-LE Perform Location request, the lowest priority shall be assumed. 
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5.2 Connection Oriented Information Transfer 

The Connection Oriented Information transfer procedure is applicable to the Lb and Ls interfaces. It enables both way 
transfer of BSSLAP messages between an SMLC and the BSC serving a target MS. The initiator of the procedure can 
be either the BSC serving the target MS, the visited MSC for the target MS or the SMLC. The procedure is only valid 
while a location request procedure for the target MS is ongoing. The procedure makes use of SCCP connection oriented 
signaling on the Lb and Ls interfaces and uses the same SCCP connection as the location request procedure for the 
particular target MS. 

5.2.1 Successful Operation 

An SMLC, MSC or BSC with a BSSLAP message or message segment to transfer concerning a particular target MS 
sends a BSSMAP-LE Connection Oriented Information message to a recipient carrying the following parameters: 

BSSLAP APDU (M) 

Segmentation (C) 

If the sender is an NSS based SMLC, the message is transferred to the VMSC for the target MS. The recipient MSC 
shall then transfer the message to the serving BSC using procedures defined in 3GPP TS 08.08. 

If the sender is a BSS based SMLC, the message is transferred to the serving BSC for the target MS. The BSC shall 
then perform the positioning operation requested by the BSSLAP APDU (refer to 3GPP TS 08.71). If the BSSLAP 
APDU contains an RRLP APDU, the BSC shall transfer this to the target MS. 

If the sender is a BSC or MSC and the intended recipient is the SMLC for a target MS, the message is transferred to the 
SMLC. The SMLC shall then perform interpretation of the BSSLAP APDU. 

5.2.2 Abnormal Conditions 

At an intermediate entity, if a received BSSMAP-LE Connection Oriented Information message contains unrecognized 
information or if the message cannot be sent on, the message shall be discarded. 

At the receipient entity, if a received BSSMAP-LE Connectioin Oriented Information message contains invalid or 
unrecognized information as defined for BSSAP-LE, any ongoing positioning procedure shall be terminated and 
associated resources may be released. If the receipient is a BSC, the SMLC shall be notified - e.g. using a BSSLAP 
Reject or Abort. If the receipient is an SMLC, a new positioning attempt (e.g. using a different position method) may be 
started. 

5.2.3 Segmentation 

The Segmentation parameter shall not be included if the BSSLAP message is not segmented. 

If the size of an embedded BSSLAP message is too large to fit into one BSSMAP-LE message, the sending entity 
divides the BSSLAP message to a necessary number of BSSMAP-LE messages each containing a BSSLAP APDU IE 
and a Segmentation IE. In the BSSLAP APDU IE it includes as many octets as possible. 

The segmentation IE contains a segment number field and an indication of the final segment. Message identification 
shall not be used. The order number of a segment in the Segment Number field in the Segmentation IE is incremented 
by one starting from zero, i.e. the value is for the first segment, 1 for the next and so on. The receiving entity may use 
the segment number in order to recognize the start of a new BSSLAP message and verify that all segments were reliably 
transferred. 

In case of handover interrupting the information transfer procedure, the exception procedures described in 
3GPP TS 03.71 shall be used. 
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5.3 Connectionless Information Transfer 

The Connectionless Information transfer procedure is applicable to the Lb, Ls and Lp interfaces. It enables both way 
transfer of LLP messages between an SMLC and a Type B LMU. The procedure also enables both way transfer of 
SMLCPP messages between two SMLCs. The initiator of the procedure can be a BSC, MSC or SMLC. The procedure 
makes use of SCCP connectionless signaling. 

5.3.1 Successful Operation 

An SMLC, MSC or BSC needing to transfer an LLP message concerning a Type B LMU or an SMLCPP message sends 
a BSSMAP-LE Connectionless Information message to a recipient carrying the following parameters: 

Source Entity (M) 

Destination Entity (M) 

APDU (M) 

Segmentation (C) 

Return Error Request (O) 

The source entity identifies the sender. The recipient entity identifies the final destination. The Segmentation IE 
provides segmentation and message identification for a segmented APDU. The Return Error Request may be included 
to request notification in the event of unsuccessful transfer and indicate the type of notification needed. If the recipient 
entity is not the final destination, the recipient shall transfer the BSSMAP-LE Connectionless Information message to 
either the final destination or an intermediate MSC or BSC capable of onward transfer to the final destination. 

5.3.2 Unsuccessful Operation 

If the message cannot be transferred by an intermediate entity or destination entity (e.g. reassembly of a segmented 
message fails) and the Return Error Request is not included, the message shall be discarded. If the Return Error Request 
is included, the intermediate or destination entity shall, depending on the Return Error Request type, send a BSSMAP- 
LE Connectionless Information message to, or towards, the original source containing the following parameters: 

Source Entity (M) 

Destination Entity (M) 

APDU (C) 

Segmentation (C) 

Return Error Cause (M) 

The Source entity shall indicate the Destination Entity in the original received message. The Destination Entity shall 
indicate the Source Entity in the original message. The Return Error cause shall indicate the reason for unsuccessful 
transfer. The APDU and Segmention lEs shall, depending on the the Return Error Request type, contain any originally 
received APDU and Segmentation lEs, respectively. 

If a received BSSMAP-LE Connectionless Information message containing a Return Error Cause cannot be transferred 
by an intermediate entity, it shall be discarded with no return error message. 

5.3.3 Abnormal Conditions 

At an intermediate entity, if a received BSSMAP-LE Connectionless Information message contains unrecognized or 
invalid information, the message shall be discarded. 

At the recipient entity, if a received BSSMAP-LE Connectioinless Information message contains invalid or 
unrecognized information as defined for BSSAP-LE, the message shall be discarded. 
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5.3.4 Segmentation 

The Segmentation parameter shall not be included if the APDU is not segmented. 

If the size of an APDU containing an embedded SMLCPP message is too large to fit into one BSSMAP-LE message, 
the sending entity divides the SMLCPP message to a necessary number of BSSMAP-LE messages each containing an 
APDU IE and a Segmentation IE. In the APDU IE it includes as many octets as possible 

The segmentation IE contains a segment number, an indication of the final segment and the message ID. The order 
number of a segment in the Segment Number field in the APDU IE is incremented by one starting from zero, i.e. the 
value is for the first segment, 1 for the next and so on. The receiving entity recognizes that a segment is missing or 
duplicated, when 

There is more than one segment with the same segment number and same Message ID. 

The segment number does not increase by steps of one starting from zero. 

If the recipient recognizes a missing or duplicated element, it shall discard the entire message (i.e. all received segment 
with the message ID). 

The message identity in the Message ID field in the APDU IE is used to recognize a particular message to which that 
segment belongs. The sending entity can select any of the available values (0-65535) that is not currently used between 
it and the receiving entity. 

If an APDU segment is received with Return Errror cause IE (due to invocation of the return error option), reassembly 
does not apply and the APDU segment and error cause maybe returned to the original source application. 

5.4 LMU Connection Establisinment 

The LMU Connection Establishment procedure is applicable to the Ls interface. Its purpose is to establish a signaling 
connection between an SMLC and Type A LMU via the visted MSC for the LMU. The procedure can be initiated by 
either the SMLC or MSC. The procedure makes use of SCCP connection oriented signaling on the Ls interface. 

5.4.1 LIVIU Connection Establisinment initiated by tine SMLC 
5.4.1.1 Successful Operation 

The SMLC sends a BSSMAP-LE LMU Connection Request message to the VMSC for the LMU. This message 
contains the following parameters. 

IMSI (M) 

Sender Address (O) 

Security (C) 

The IMSI identifies the LMU. The sender address, if included, identifies the SMLC. The Security parameter shall be 
included if authentication or ciphering of the LMU are required. On receipt of this message, the MSC shall attempt to 
establish a signalling link to the LMU (refer to 3GPP TS 03.71). Authentication and ciphering shall be invoked if 
requested by the SMLC. Once the signaling link has been established, the MSC shall return a BSSMAP-LE LMU 
Connection Accept to the SMLC with the following parameters. 

Call Number (O) 

The call number shall be included if the MSC has the capability to support signaling to an LMU using a traffic channel 
(refer to 3GPPTS 03.71). 
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5.4.1.2 Unsuccessful Operation 

If the LMU is not recognized in the MSC (e.g. no VLR record) or a signaling link cannot be setup to the LMU (e.g. 
paging of the LMU fails) or authentication or ciphering cannot be performed when requested by the SMLC, any 
signaling link to the LMU shall be released, if not required for other MM or CM procedures and a BSSMAP-LE LMU 
Connection Reject shall be returned to the SMLC with the following parameters. 

Reject Cause (M) 

5.4.1.3 Abnormal Conditions 

If the SMLC or MSC detects release of the SCCP connection on the Ls interface for an LMU, the connection 
establishment procedure shall be considered to have failed and any associated resources may be released. 

5.4.2 LMU Connection Establishment initiated by the MSC 

5.4.2.1 Successful Operation 

The MSC shall initiate the LMU connection establishment procedure when no LMU connection to the SMLC currently 
exists and the MSC receives a CM Service Request from the LMU specifying the LCS service. The MSC shall then 
send a BSSMAP-LE LMU Connection Request message to the SMLC associated with either the IMSI or current cell 
location of the LMU. This message shall contain the following parameters. 

IMSI (M) 

Sender Address (M) 

Call Number (C) 

The IMSI identifies the LMU. The sender address identifies the MSC. The call number shall be included if the MSC has 
the capability to support signaling to an LMU using a traffic channel (refer to 3GPP TS 03.71). On receipt of this 
message, the SMLC shall return a BSSMAP-LE LMU Connection Accept to the MSC with the following parameters. 

Security (C) 

The Security parameter shall be included if authentication or ciphering of the LMU are required On receipt of this 
message, the MSC shall perform authentication and/or ciphering if requested by the SMLC and shall complete the 
establishment of an MM connection to the LMU to support LCS. 

5.4.2.2 Unsuccessful Operation 

If the LMU is not recognized in the SMLC or a signaling connection cannot be supported (e.g. due to congestion), a 
BSSMAP-LE LMU Connection Reject shall be returned to the MSC with the following parameters. 

Reject Cause (M) 

The MSC shall then reject the CM service request from the LMU. 

5.4.2.3 Abnormal Conditions 

If the SMLC or MSC detects release of the SCCP connection on the Ls interface for an LMU, the connection 
establishment procedure shall be considered to have failed and any associated resources may be released. 

5.5 LMU Connection Release 

The LMU Connection Release procedure is applicable to the Ls interface. Its purpose is to release a signaling 
connection between an SMLC and Type A LMU. The procedure can be initiated by either the SMLC or MSC. The 
procedure makes use of SCCP connection oriented signaling on the Ls interface. 



£75/ 



3GPP TS 09.31 version 7.8.0 Release 1 998 16 ETSI TS 1 01 530 V7.8.0 (2004-05) 

5.5.1 LMU Connection Release initiated by tine SMLC 

5.5.1.1 Successful Operation 

The SMLC sends a BSSMAP-LE LMU Connection Release message to the VMSC for the LMU. This message 
contains the following parameters. 

Release Cause (M) 

On receipt of this message, the MSC shall release the main signaling link to the LMU unless required for other ongoing 
MM and CM procedures in the MSC. The MSC shall also initiate release of the SCCP connection to the SMLC for the 
LMU. 

5.5.1.2 Abnormal Conditions 

The SMLC may initiate release of the signaling connection to an LMU by initiating release of the SCCP connection for 
the LMU to the MSC. The MSC shall then release the main signaling link to the LMU unless required for other ongoing 
MM or CM procedures. 

5.5.2 LMU Connection Release initiated by the MSC 

5.5.2.1 Successful Operation 

The MSC shall initiate release of an LMU connection to an SMLC if the main signaling link to the LMU is released. 
The MSC sends a BSSMAP-LE LMU Connection Release message to the SMLC for the LMU. This message contains 
the following parameters. 

Release Cause (M) 

On receipt of this message, the SMLC should initiate release of the SCCP connection to the MSC for the LMU. 

5.5.2.2 Abnormal Conditions 

The MSC may initiate release of the signaling connection between an SMLC and LMU by initiating release of the 
SCCP connection for the LMU to the SMLC. 

5.6 DTAP-LE Information Transfer 

The DTAP-LE Information transfer procedure is applicable to the Ls interface. It supports bothway LLP message 
transfer between an NSS based SMLC and Type A LMU. The procedure is only valid when a signaling connection 
between an SMLC and Type A LMU has been established. The procedure uses SCCP connection oriented signaling 
using the SCCP connection previously established between the SMLC and MSC when the signaling connection 
between the SMLC and LMU was established. 

5.6.1 DTAP-LE Information Transfer Initiated by the SMLC 

The SMLC initiates the procedure when it has an LLP message to transfer to a type A LMU. The message may first be 
segmented. The SMLC shall then transfer each LLP segment to the MSC inside a DTAP-LE REGISTER, FACILITY or 
RELEASE COMPLETE message. The usage of these messages is as defined in 3GPP TS 04.71. The MSC relays each 
DTAP-LE message to the LMU. 

5.6.2 DTAP-LE Information Transfer Initiated by the MSC 

The MSC initiates the procedure when a DTAP message is received from an LMU containing the LCS protocol 
discriminator. The MSC then relays the DTAP message to the SMLC. 
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5.7 Reset 

The reset procedure is an optional procedure within a PLMN applicable to the Lb and Ls interfaces. It enables an 
SMLC, MSC or BSC that has undergone a failure with loss of memory of LMU signalling connections and location 
service transactions to indicate this to a partner entity (SMLC, MSC or BSC). The recipient entity can then release its 
own connection and transaction resources. The reset procedure may not be applicable when only a limited part of an 
SMLC, MSC or BSC has suffered a failure, since error recovery procedures specific to individual connections and 
transactions may then be used. 

5.7.1 Normal Operation 

In the event of a failure at an SMLC, MSC or BSC that results in the loss of LMU connection information and location 
service information, a Reset message may be sent to the partner SMLC, MSC or BSC across the Lb or Ls interface. The 
message carries no parameters and is sent using connectionless SCCP procedures. The sending entity shall ensure that 
all information on LMU connections and location service transactions to the other entity is reinitialized to indicate no 
existing connections and transactions. 

On receiving a Reset message, the recipient SMLC, MSC or BSC shall clear all references and state information for 
LMU connections and location service transactions to the sending entity and shall release any associated resources 
including, in the case of a recipient MSC or BSC, any signaling connections or circuit connections to LMUs controlled 
by a sending SMLC. The recipient entity shall then return a Reset Acknowledge message. 

For a reset on the Lb interface where the SMLC and BSC support circuit connections to LMUs (in addition to signaling 
connections), the entity that does not control assignment of circuits shall initiate blocking procedures (Block or Circuit 
Group Block procedure as defined in 3GPP TS 08.08) for all circuits that are locally blocked on its own side. The 
initiation of blocking may occur before sending or receipt, whichever applies, of the Reset Acknowledge. 

5.7.2 Abnormal Conditions 

If an initiating SMLC, MSC or BSC receives no response to a Reset message following an O&M administered time 
period, it shall resend the Reset message. For successive no response conditions, sending shall occur a maximum of "n" 
times, where "n" is an O&M administered parameter. Following "n" unsuccessful, reset attempts, the procedure shall be 
terminated and maintenance shall be informed. 



6 Usage of BSSAP-LE and BSSAP on the Lb Interface 

6.1 Applicable Message Sets 

The following BSSAP-LE message sets are applicable to the Lb interface between an SMLC and BSC: 

All DTAP-LE messages 

All BSSMAP-LE positioning messages 

All BSSMAP-LE information messages 

All BSSMAP-LE general messages 

The following BSSMAP messages defined in 3GPP TS 08.08 are applicable to the Lb interface to support signaling to a 
Type A LMU using an SDCCH: 

Cipher Mode Command (SMLC to BSC) 

Cipher Mode Complete (BSC to SMLC) 

Cipher Mode Reject (BSC to SMLC) 

Classmark Update (BSC to SMLC) 

Clear Command (SMLC to BSC) 
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Clear Complete (BSC to SMLC) 

Clear Request (BSC to SMLC) 

Complete Layer 3 Information (BSC to SMLC) 

Confusion (BSC to SMLC) 

Handover Required (BSC to SMLC) 

Handover Required Reject (SMLC to BSC) 

Handover Performed (BSC to SMLC) 

Paging (SMLC to BSC) 

The following additional BSSMAP messages defined in 3GPP TS 08.08 are applicable to the Lb interface to support 
signaling to a Type A LMU using a TCH: 

Assignment Request (SMLC to BSC) 

Assignment Complete (BSC to SMLC) 

Assignment Failure (BSC to SMLC) 

Block (bothway) 

Blocking Acknowledge (bothway) 

Unblock (bothway) 

Unblocking Ack. (bothway) 

Unequipped circuit (bothway) 

The following DTAP messages defined in 3GPP TS 04.08 are applicable to the Lb interface to support signaling to a 
Type A LMU using an SDCCH: 

RR Paging Response 

All MM Messages 

The following additional CM level DTAP messages defined in 3GPP TS 04.08 are applicable to the Lb interface to 
support signaling to a Type A LMU using a TCH. 

Call Confirmed (LMU to SMLC) 

Connect (LMU to SMLC) 

Connect Acknowledge (SMLC to LMU) 

Setup (SMLC to LMU) 

Disconnect (bothway) 

Release (bothway) 

Release Complete (bothway) 

6.2 MTP Functions 

Except where defined otherwise in this specification, MTP requirements on the Lb interface for the BSC are the same as 
those defined for the A interface in 3GPP TS 08.06 for the BSC. MTP requirements on the Lb interface for the SMLC 
are the same as those defined for the A interface in 3GPP TS 08.06 for the MSC. STP functions are not required in the 
SMLC and a single signaling link set may be used between the BSC and SMLC. The BSC shall be homed to a single 
SMLC and shall only use the Lb signaling interface for signaling communication with the SMLC. 
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6.3 



SCCP Functions 



6.3.1 General 

Except where defined otherwise in this specification, SCCP requirements on the Lb interface for the BSC are the same 
as those defined for the A interface in 3GPP TS 08.06 for the BSC. SCCP requirements on the Lb interface for the 
SMLC are the same as those defined for the A interface in 3GPP TS 08.06 for the MSC. Requirements concerning 
support of a type A LMU are the same as those in 3GPP TS 08.06 regarding support of a normal MS. In particular, 
usage of SCCP to transfer DTAP-LE messages between a type A LMU and SMLC are the same as those regarding 
transfer of other DTAP messages. 

6.3.2 Modifications for Connectionless SCCP 

Connectionless SCCP messages and procedures are used to transfer BSSMAP-LE Connectionless Information 
messages and those BSSMAP messages applicable to the Lb interface for which connectionless SCCP transfer is 
defined in 3GPP TS 08.08. Refer to 3GPP TS 03.71 for a description of the procedures in the SMLC and BSC. SCCP 
protocol class 1 shall be used when multiple BSSMAP-LE messages are transferred containing segments of a single 
fragmented LLP or SMLCPP message. 

6.3.3 Modifications for Connection Oriented SCCP 

Use of connection oriented SCCP messages and procedures on the Lb interfaces to support signaling access to a type A 
LMU using DTAP-LE, DTAP and BSSMAP messages is the same as that defined in 3GPP TS 08.06 on the A 
interface to support access to a normal MS. 

To support positioning of a target MS, connection oriented SCCP messages and procedures using protocol class 2 shall 
be used to transfer BSSMAP-LE positioning messages and BSSMAP-LE Connection Oriented Information messages 
over the Lb interface. A separate dedicated SCCP connection shall be used to support positioning for each target MS. 
Connection establishment shall be instigated by the BSC when the positioning attempt commences. Connection release 
shall be instigated by either the BSC or SMLC when the positioning attempt has been completed or has failed. 

Transfer of BSSMAP-LE messages using an SCCP connection to support positioning of a particular target MS is 
shown in the following figure. In particular, a BSSMAP-LE message shall be included in the data field of the SCCP 
CR and a BSSMAP-LE message may be included in the data field of an SCCP CC, CREF or RLSD message. 
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Figure 6.3.3/09.31 : SCCP Connection Oriented Signaling on Lb Interface for Positioning 
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6.3.4 Contents of the SCCP Data Field 

The contents of the SCCP data field are the same as that defined for the A interface in 3GPP TS 08.06 for MSC-BSC 
signaling. In particular, the same conventions are used to transfer and discriminate between any BSSAP and DTAP 
message contained within the SCCP data field. Since all BSSAP-LE messages applicable to the Lb interface use the 
same encoding as for the A interface, the conventions used to discriminate a BSSMAP message are applicable to any 
BSSMAP-LE message on the Lb interface, while the conventions for a DTAP message apply to any DTAP-LE 
message. 

6.3.5 Abnormal Conditions 

If a user-out-of-service information or signalling-point-inaccessible information is received by a BSC or SMLC, no new 
attempt to establish SCCP connections towards the affected point code shall be started until the corresponding user-in- 
service information or signalling-point-accessible information is received. 

When a user-out-of-service information or signalling-point-inaccessible is received, an optional timer may be started. If 
the timer expires all the SCCP connections towards the affected point code shall be released. When the user-in-service 
or signalling-point-accessible is received, the timer is stopped. 

If an SCCP connection is released, the optional timer expires or a connection refusal is received, any dependent 
BSSAP-LE procedure between the SMLC and BSC shall be terminated and, at a BSC, any associated SCCP connection 
or location service transaction to an MSC, or any associated signaling or circuit connection to an LMU, shall be 
released using appropriate signalling procedures. 



7 Use of BSSAP-LE on the Ls Interface 

7.1 Applicable Message Sets 

The following BSSAP-LE messages are appUcable to the Ls interface between an MSC and SMLC: 
All DTAP-LE messages 
All BSSMAP-LE positioning messages 
All BSSMAP-LE LMU control messages 
All BSSMAP-LE information messages 
All BSSMAP-LE general messages 

7.2 MTP Functions 

SS7 signaling on the Ls interface may be supported using 56 kbps or 64 kbps digital signaling channels. These may be 
supported within either El or Tl physical links. 

For El links or where CCITT/ITU SS7 signaling is applicable, the MTP functions as specified in CCITT 
Recommendations Q.702, Q.703, Q.704 and Q.707 are applicable. For Tl links or where ANSI SS7 signaling is 
applicable, the MTP functions as specified in ANSI Tl . Ill are applicable. For the SMLC, the requirements in these 
recommendations for a signaling end point are applicable. For the MSC, the requirements in these recommendations for 
both a signaling end point and signaling transfer point (STP) are applicable. MSC support of STP functions is only 
required for situations in which the SMLC has no signaling links to an STP and needs to access other network entities to 
which there are no direct point-to-point signaling links. 

Where an SMLC supports direct signaling links to one or more MSCs only and has no signaling links to an STP, certain 
exceptions and modifications to normal CCITT and ANSI requirements may be applied within a PLMN administration. 
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7.3 SCCP functions 

7.3.1 General 

For El links or where CCITT/ITU SS7 signaling is applicable, the SCCP functions as specified in either CCITT Blue 
Book Recommendations Q.71 1, Q.712, Q.713 and Q.714 or ITU White Book Recommendations Q.711, Q.712, Q.713 
and Q.714 are applicable, as amended by the exceptions and modifications defined here. For Tl links or where ANSI 
SS7 signaling is applicable, the SCCP functions as specified in ANSI Tl.l 12 are applicable, as amended by the 
exceptions and modifications defined here. 

Several functions of the SCCP are not used on the Ls interface: error detection, receipt confirmation, flow control. 

The segmenting/reassembling function may be used if the total message length exceeds the maximum allowed message 
length that can be carried by the MTP. 

7.3.2 Allowed Exceptions to CCITT Recommendations Q.71 1 -71 4 

Only the following SCCP messages are applicable to the Ls interface: 

Connection Confirm (CC) 

Connection Request (CR) 

Connection Refused (CREF) 

Data Form 1 (DTI) 

Inactivity Test (IT) 

Released (RLSD) 

Release Complete (RLC) 

Subsystem Allowed (SSA) 

Subsystem Prohibited (SSP) 

Subsystem Status Test (SST) 

Unitdata (UDT) 

Unitdata Service (UDTS) 

Support of only SCCP protocol classes 0, 1 and 2 is required. For protocol class 2, the "credit" parameter field and the 
"sequencing/segmenting" parameter fields are not used, but the parameters must still be included in the Inactivity Test 
(IT) message for syntax reasons. Negotiation of protocol class and flow control is not required for protocol class 2. 

The SCCP called party address in a CR or UDT may contain only the subsystem number (SSN) or a signaling point 
code (SPC) plus SSN or a global title. Use of a global title is not required for SMLC to MSC signaling within the same 
PLMN. SSN values applicable to the Ls interface are defined in 3GPP TS 03.03. 

For protocol class 2, support of only a single connection section is required. Use of multiple connection sections is a 
national concern. 
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7.3.3 Allowed Exceptions to ANSI T1 . 11 2 

Only the following SCCP messages are applicable to the Ls interface: 

Connection Confirm (CC) 

Connection Request (CR) 

Connection Refused (CREF) 

Data Form 1 (DTI) 

Inactivity Test (IT) 

Released (RLSD) 

Release Complete (RLC) 

Subsystem Allowed (SSA) 

Subsystem Prohibited (SSP) 

Subsystem Status Test (SST) 

Unitdata (UDT) 

Unitdata Service (UDTS) 

Support of only SCCP protocol classes 0, 1 and 2 is required. For protocol class 2, the "credit" parameter field and the 
"sequencing/segmenting" parameter fields are not used, but the parameters must still be included in the Inactivity Test 
(IT) message for syntax reasons. Negotiation of protocol class and flow control is not required for protocol class 2. 

The SCCP called party address in a CR or UDT may contain only the subsystem number (SSN) or a signaling point 
code (SPC) plus SSN or a global title. Use of a global title is not required for SMLC to MSC signaling within the same 
PLMN. SSN values applicable to the Ls interface are defined in 3GPP TS 03.03. 

For protocol class 2, support of only a single connection section is required. Use of multiple connection sections is a 
national concern. 



7.3.4 Usage of Connectionless SCCP 



Connectionless SCCP messages and procedures are used to transfer BSSMAP-LE Connectionless Information 
messages. Refer to 3GPP TS 03.71 for a description of the procedures in the SMLC and MSC. SCCP protocol class 1 
shall be used when multiple BSSMAP-LE messages are transferred containing segments of a single fragmented LLP or 
SMLCPP message. 

7.3.5 Usage of Connection Oriented SCCP 

Connection oriented SCCP messages and procedures for SCCP protocol class 2 shall be used to transfer BSSMAP-LE 
positioning messages, BSSMAP-LE LMU control messages, BSSMAP-LE Connection Oriented Information messages 
and DTAP-LE messages. A separate dedicated SCCP connection shall be used to support either positioning for each 
target MS or signaling to each type A LMU. Connection establishment shall be instigated when the positioning attempt 
commences or when a signaling link to a type A LMU needs to be established. Connection release shall be instigated 
when the positioning attempt has been completed or has failed or when a signaling link to a type A LMU needs to be 
released. The MSC is normally expected to release the SCCP connection to the SMLC. 

Transfer of BSSAP-LE messages within an SCCP connection is shown in the following figure. In particular, a 
BSSMAP-LE message shall be included in the data field of any SCCP CR and a BSSMAP-LE message may be 
included in the data fields of an SCCP CC, CREF or RLSD message. 
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MSC or SMLC 
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Figure 7.3.5-1/09.31 : SCCP Connection Oriented Signaling on Ls Interface 

7.3.6 Contents of the SCCP Data Field 

The contents of the SCCP data field for BSSMAP-LE and DTAP-LE messages are shown in the following figures. 
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Figure 7.3.6-1/3GPP TS 09.31 : SCCP Data Field for a BSSMAP-LE Message 
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Figure 7.3.6-2/3GPP TS 09.31 : SCCP Data Field for a DTAP-LE Message 

The Discrimination Indicator is coded in bit 1 of octet one and indicates the type of the BSSAP-LE message. 



Discrmination Indicator 


BSSAP-LE Message Type 





BSSMAP-LE 


1 


DTAP-LE 



The DLCI in octet 2 is applicable only to DTAP-LE messages and is coded as defined for the A interface in 
3GPP TS 08.06 for DTAP. For signaling to a type A LMU using an SDCCH and SAPI=0, the value of the DLCI is 
10000000. 

The length indicator is coded in one octet, and is the binary representation of the number of octets of the subsequent 
BSSMAP-LE or DTAP-LE message parameter. 



£75/ 



3GPP TS 09.31 version 7.8.0 Release 1 998 24 ETSI TS 1 01 530 V7.8.0 (2004-05) 



7.3.7 Content of DTAP-LE Messages 



DTAP-LE messages transferred on the Ls interface are encoded as defined in 3GPP TS 04.71. In particular, in octet 1 of 
any DTAP-LE message, the Protocol discriminator shall indicate LCS and the transcation identifier (Tl) shall indicate 
the transcation between the SMLC and type A LMU. The Tl shall be assigned by the SMLC if the transcation is 
originated from the SMLC and by the LMU if the originator is the LMU. The MSC shall not change the value of the Tl 
when transferring any DTAP-LE message from the SMLC to the LMU or from the LMU to the SMLC. 

7.3.8 Abnormal Conditions 

If a user-out-of-service information or signalling-point-inaccessible information is received by an MSC or SMLC, no 
new attempt to establish SCCP connections towards the affected point code shall be started until the corresponding 
user-in-service information or signalling-point-accessible information is received. 

When a user-out-of-service information or signalling-point-inaccessible is received, an optional timer may be started. If 
the timer expires all the SCCP connections towards the affected point code shall be released. When the user-in-service 
or signalling-point-accessible is received, the timer is stopped. 

If an SCCP connection is released, the optional timer expires or a connection refusal is received, any dependent 
BSSAP-LE procedure between the SMLC and MSC shall be terminated and, at an MSC, any associated SCCP 
connection or location service transaction to a BSC, or any associated signaling or circuit connection to an LMU, shall 
be released using appropriate signalling procedures. 



8 Use of BSSAP-LE on the Lp Interface 

8.1 Applicable Message Sets 

The following BSSAP-LE messages are applicable to the Lp interface between an SMLC and a peer SMLC. 
BSSMAP-LE Connectionless Information message. 

8.2 MTP Functions 

SS7 signaling on the Lp interface may be supported using 56 kbps or 64 kbps digital signaling channels. These may be 
supported within either El or Tl physical links. 

Two SMLCs may be connected by direct point-to-point SS7 signaling links or links may be employed via intermediate 
STPs. Alternatively, signaling transfer between two SMLCs may be supported via intermediate BSCs and/or MSCs 
using the Lb and/or Ls interfaces. Signaling requirements to support message transfer on the Lp interface via an 
intermediate Lb or Ls interface are the same as those defined elsewhere in this specification for these interfaces. This 
section defines the requirements applicable to direct SMLC-SMLC SS7 links and SS7 links from an SMLC to an STP. 

For El links or where CCITT/ITU SS7 signaling is applicable, the MTP functions as specified in CCITT 
Recommendations Q.702, Q.703, Q.704 and Q.707 are applicable. For Tl links or where ANSI SS7 signaling is 
applicable, the MTP functions as specified in ANSI Tl.lll are applicable. Only the requirements in these 
recommendations for a signaling end point are applicable. 

Where an SMLC has no signaling links to an STP, certain exceptions and modifications to normal CCITT and ANSI 
requirements may be applied within a PLMN administration. 
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8.3 SCCP functions 

8.3.1 General 

For El links or where CCITT/ITU SS7 signaling is applicable, the SCCP functions as specified in either CCITT Blue 
Book Recommendations Q.71 1, Q.712, Q.713 and Q.714 or ITU White Book Recommendations Q.711, Q.712, Q.713 
and Q.714 are applicable, as amended by the exceptions and modifications defined here. For Tl links or where ANSI 
SS7 signaling is applicable, the MTP functions as specified in ANSI T1.112 are applicable, as amended by the 
exceptions and modifications defined here. 

8.3.2 Allowed Exceptions to CCITT Recommendations Q.71 1 -71 4 

Only the following SCCP messages are applicable to the Lp interface: 

Inactivity Test (IT) 

Subsystem Allowed (SSA) 

Subsystem Prohibited (SSP) 

Subsystem Status Test (SST) 

Unitdata (UDT) 

Unitdata Service (UDTS) 

Support of only SCCP protocol classes and 1 is required. 

The SCCP called party address in a UDT may contain only the subsystem number (SSN) or a signaling point code 
(SPC) plus SSN or a global title. Use of a global title is not required for SMLC to SMLC signaling within the same 
PLMN. SSN values applicable to the Lp interface are defined in 3GPP TS 03.03. 

8.3.3 Allowed Exceptions to ANSI Tl . 1 1 2 

Only the following SCCP messages are applicable to the Lp interface: 

Inactivity Test (IT) 

Subsystem Allowed (SSA) 

Subsystem Prohibited (SSP) 

Subsystem Status Test (SST) 

Unitdata (UDT) 

Unitdata Service (UDTS) 

Support of only SCCP protocol classes and 1 is required. 

The SCCP called party address in a UDT may contain only the subsystem number (SSN) or a signaling point code 
(SPC) plus SSN or a global title. Use of a global title is not required for SMLC to SMLC signaling within the same 
PLMN. SSN values applicable to the Lp interface are defined in 3GPP TS 03.03. 

8.3.4 Usage of Connectionless SCCP 

Connectionless SCCP messages and procedures shall be used to transfer BSSMAP-LE Connectionless Information 
messages. Refer to 3GPP TS 03.71 for a description of the procedures in the SMLC. SCCP protocol class 1 shall be 
used when multiple BSSMAP-LE messages are sent containing segments of a single fragmented SMLCPP message. 
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8.3.5 Usage of Connection Oriented SCCP 

Connection oriented SCCP messages and procedures are not applicable to the Lp interface. 

8.3.6 Contents of the SCCP Data Field 

The contents of the SCCP data field is shown in the following figure. 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 























D=0 


Octet 2 


Length indicator = n 


Octet 3 

to 

Octet n+2 


BSSMAP-LE Message Contents 



Figure 8.3.6-1/3GPP TS 09.31 : SCCP Data Field for a BSSIVIAP-LE IVIessage 

The Discrmination Indicator is coded in bit 1 of octet one and indicates the type of the BSSAP-LE message. 



Discrminatlon Indicator 


BSSAP-LE Message Type 





BSSMAP-LE 



The length indicator is coded in one octet, and is the binary representation of the number of octets of the subsequent 
BSSMAP-LE message parameter. 



9 Message Functional Definitions and Contents 

For each message there is, in this clause, a table listing the signalling elements in their order of appearance in the 
transmitted message. 

9.1 BSSIVIAP-LE PERFORM LOCATION REQUEST message 

This message is sent to request a location estimate for a target MS and contains sufficient information to enable location 
according to the required QoS using any positioning method supported by the PLMN and, where necessary, MS. The 
message is also used to request LCS assistance data transfer to an MS or request a deciphering keys for LCS broadcast 
assistance data The message can be sent from the BSC to the SMLC and from the MSC to the SMLC. 

Table 9.1 : BSSIVIAP-LE PERFORM LOCATION REQUEST message content 



Information element 


Type / Reference 


Presence 


Format 


Length in octets 


Message type 


Message Type 


M 


V 


1 


Location Type 


Location Type 


M 


TLV 


3-4 


Cell Identifier 


Cell Identifier 


M 


TLV 


3-10 


Classmark Information Type 3 


Classmark Information Type 3 


Q 


TLV 


2-n 


LCS Client Type 


LCS Client Type 


C 


TLV 


3 


Ciiosen Cinannel 


Chosen Channel 





TLV 


2-n 


LCS Priority 


LCS Priority 





TLV 


3 


LCS QoS 


LCS QoS 


Q 


TLV 


6 


GPS Assistance Data 


GPS Assistance Data 


Q 


TLV 


3-n 


BSSLAP APDU 


APDU 


Q 


TLV 


2-n 



9.1.1 Location Type 

This parameter defines the type of locatin information being requested. 
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9.1.2 Cell Identifier 

This parameter gives the current cell location of the target MS. The format shall either be the cell global identification 
or the LAC plus CI form. 

9.1 .3 Classmark Information Type 3 

This parameter indicates the positioning methods supported by the MS as obtained from the MS Classmark 3 received 
earlier from the target MS. 

9.1.4 LCS Client Type 

This parameter defines the type of the originating LCS Client. It shall be included if the Location Type indicates a 
request for a location estimate and the LCS Client Type is for Emergency Services and may be included in other cases 
to assist an SMLC to appropriately prioritize a location request 

9.1.5 Chosen Channel 

This parameter defines the type of radio channel currently assigned to the target MS. 

9.1.6 LCS Priority 

This parameter defines the priority of the location request. 

9.1.6a LCSQoS 

This parameter provides the required Quality of Service for the LCS Request. Quality of Service may include horizontal 
accuracy, vertical accuracy and allowed response time. 

9.1 .7 GPS Assistance Data 

This parameter identifies the specific GPS assistance data that may be requested. 

9.1.8 BSSLAPAPDU 

This parameter provides additional measurements (e.g. timing advance) for the target MS from the BSC. The 
measurements are contained inside a BSSLAP APDU. 

9.2 BSSMAP-LE PERFORM LOCATION RESPONSE message 

This message is sent in response to a BSSMAP-LE Perform Location Request to return a successful location estimate 
for a target MS or to indicate some failure in obtaining this. The message is also sent in response to a BSSMAP-LE 
Perform Location Request to return deciphering keys or an indication that LCS assistance data has been successfully 
deUvered to an MS. The message can be sent from the SMLC to the BSC and from the SMLC to the MSC. 

Table 9.2: BSSMAP-LE PERFORM LOCATION RESPONSE message content 



Information element 


Type / Reference 


Presence 


Format 


Length in octets 


Message type 


Message Type 


M 


V 


1 


Location Estimate 


Geographic Location 


C 


TLV 


2-22 


Positioning Data 


Positioning Data 





TLV 


2-n 


Decipliering Keys 


Decipliering Keys 





TLV 


17 


LCS Cause 


LCS Cause 





TLV 


3 



9.2.1 Location Estimate 

This parameter provides a location estimate for the target MS in the case of a successful location attempt. 
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9.2.2 Positioning Data 

This parameter provides additional information for the positioning attempt from the SMLC. 

9.2.3 Deciplnering Keys 

This parameter provides two deciphering keys that can be used to decode LCS broadcast assitance data by the MS. The 
SMLC shall provide the current deciphering key for the MS's present location. The SMLC shall also provide the next 
deciphering key applicable after the current deciphering key. 

9.2.4 LCS Cause 

The LCS Cause is included if and only if a requested location estimate was not successfully obtained (e.g. location 
estimate not available), requested deciphering keys were not successfully returned or requested LCS assistance data was 
not successfully transferred to the MS. The parameter provides the reason for the failure. If the LCS Cause is included, 
the Location Estimate and Deciphering Key shall not be included. 

9.3 BSSMAP-LE PERFORM LOCATION ABORT message 

This message is sent by the instigator of a location request to abort the positioning attempt or the request for assistance 
data or deciphering keys. This message can be sent from the MSC to the SMLC and from the BSC to the SMLC. 

Table 9.3: BSSMAP-LE PERFORM LOCATION ABORT message content 



Information element 


Type / Reference 


Presence 


Format 


Length in octets 


Message type 


Message Type 


M 


V 


1 


LCS Cause 


LCS Cause 


M 


TLV 


3 



9.3.1 LCS Cause 

The LCS Cause provides the reason for the aborting the location attempt. 

9.4 BSSMAP-LE LMU CONNECTION REQUEST message 

This message is sent to request the establishment of a signaling connection between an LMU and an SMLC. The 
message can be sent from an SMLC to an MSC and from an MSC to an SMLC. 

Table 9.4: BSSMAP-LE LMU CONNECTION REQUEST message content 



Information element 


Type / Reference 


Presence 


Format 


Length in octets 


Message type 


Message Type 


M 


V 


1 


IMSI 


IMSI 


M 


TLV 


3-10 


Sender Address 


Signaling Point Code 





TLV 


2-n 


Security 


Security 





TLV 


2-n 


Call Number 


ISDN Address 





TLV 


3-n 



9.4.1 IMSI 

This parameter identifies the LMU using its E.212 IMSI. 

9.4.2 Sender Address 

This parameter provides the SS7 signaling point code for the sender of the message. The parameter is mandatory for 
message transfer between an MSC and SMLC on the Ls interface. 



£75/ 



3GPP TS 09.31 version 7.8.0 Release 1998 



29 



ETSI TS 101 530 V7.8.0 (2004-05) 



9.4.3 Security 

This parameter indicates if authentication or ciphering are required for the LMU. This parameter may be included for 
message transfer from an SMLC. If the parameter is absent, authentication and ciphering shall be assumed not to be 
required. 

9.4.4 Call Number 

This parameter may be included in an LMU connection request sent by an MSC to enable the SMLC to subsequently 
estabhsh a TCH to the LMU. 

9.5 BSSMAP-LE LMU CONNECTION ACCEPT message 

This message is sent in response to a BSSMAP-LE LMU Connection Request message to accept the establishment of a 
signaling connection between an LMU and an SMLC. The message can be sent from an SMLC to an MSC and from an 
MSC to an SMLC. 

Table 9.5: BSSMAP-LE LMU CONNECTION ACCEPT message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Security 


Security 





TLV 


3 


Call Number 


ISDN Address 





TLV 


3-n 



9.5.1 Security 

This parameter indicates if authentication or ciphering are required for the LMU. This parameter may be included for 
message transfer from an SMLC. If the parameter is absent, authentication and ciphering shall be assumed not to be 
required. 

9.5.2 Call Number 

This parameter may be included in an LMU connection accept sent by an MSC to enable the SMLC to subsequently 
establish a TCH to the LMU. 

9.6 BSSMAP-LE LMU CONNECTION REJECT message 

This message is sent in response to a BSSMAP-LE LMU Connection Request message to reject the establishment of a 
signaling connection between an LMU and an SMLC. The message can be sent from an SMLC to an MSC and from an 
MSC to an SMLC. 

Table 9.6: BSSMAP-LE LMU CONNECTION REJECT message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Reject Cause 


LMU Cause 


M 


TLV 


3 



9.6.1 Reject Cause 



This parameter provides the reason for the rejection of an LMU connection. 
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9.7 BSSMAP-LE LMU CONNECTION RELEASE message 

This message is sent to release a signaling connection between an LMU and an SMLC. The message can be sent from 
an SMLC to an MSC and from an MSC to an SMLC. 

Table 9.7: BSSMAP-LE LMU CONNECTION RELEASE message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Release Cause 


LMU Cause 


M 


TLV 


3 



9.7.1 Release Cause 

This parameter provides the reason for the release of an LMU connection. 

9.8 BSSMAP-LE CONNECTION ORIENTED INFORMATION 
message 

This message is sent in association with an existing signaling connection between an SMLC and another enity to 
transfer information between the SMLC and other entity belonging to a higher level protocol. The message can be sent 
from an SMLC to an MSC, from an MSC to an SMLC, from a BSC to an SMLC and from an SMLC to a BSC. 

Table 9.8: BSSMAP-LE CONNECTION ORIENTED INFORMATION message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


BSSLAP APDU 


APDU 


M 


TLV 


3-n 


Segmentation 


Segmentation 


C 


TLV 


3 



9.8.1 BSSLAP APDU 

This parameter contains a BSSLAP message. 

9.8.2 Segmentation 

This parameter contains segmentation information for a segmented APDU. The parameter shall not include message 
information. The parameter shall be included if and only if the BSSLAP APDU is segmented. 
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9.9 BSSMAP-LE CONNECTIONLESS INFORMATION 
message 

This message conveys signaling information associated with a higher protocol level between an SMLC and another 
entity when there is no existing signaling connection association. The message can be sent from an SMLC to an MSC, 
from an MSC to an SMLC, from a BSC to an SMLC, from an SMLC to a BSC and from an SMLC to another SMLC. 

Table 9.9: BSSMAP-LE CONNECTIONLESS INFORMATION message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


IVIessage Type 


M 


V 


1 


Source Identity 


Networl< Element Identity 


M 


TLV 


3-n 


Destination Identity 


Network Element Identity 


M 


TLV 


3-n 


APDU 


APDU 





TLV 


3-n 


Segmentation 


Segmentation 


C 


TLV 


5 


Return Error Request 


Return Error Request 





TLV 


2 


Return Error Cause 


Return Error Cause 





TLV 


3 



9.9.1 Source Identity 

This parameter identifies the original source of the message. The original source can either be an SMLC or a Type B 
LMU. The source is identified by association with either a location area or a cell site. 

9.9.2 Destination Identity 

This parameter identifies the final destination of the message. The final destination can either be an SMLC or a Type B 
LMU. The destination is identified by association with either a location area or a cell site. 

9.9.3 APDU 

This parameter contains an embedded APDU. For information transfer between an SMLC and Type B LMU this shall 
be an LLP APDU. For information transfer between two peer SMLCs, this shall be an SMLCPP APDU. 

9.9.4 Segmentation 

This parameter contains segmentation and message information for a segmented APDU. The parameter shall be 
included if and only if a segmented APDU is present. 

9.9.5 Return Error Request 

This parameter may be included to request an error response if BSSMAP-LE message cannot be delivered successfully 
to its final destination. This parameter shall not be included if the Return Error cause is present. 

9.9.6 Return Error Cause 

This parameter indicates an error response for a BSSMAP-LE connectionless information message that could not be 
delivered to its final destination. The APDU should be present and the same as the APDU in the original undelivered 
message. The source and destination identies shall be included and the same as the destination and source identities, 
respectively, in the original undelivered message. 
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9.10 BSSMAP-LE RESET message 



This message is sent to indicate a failure in the sending entity with loss of memory of LMU connections and location 
service transactions that were established or were being established. The message may be sent from an SMLC to an 
MSC or BSC and from an MSC or BSC to an SMLC. 

This message is sent as a connectionless SCCP message. 

Table 9.10: BSSMAP-LE RESET message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Cause 


Cause 


M 


TLV 


3-4 



9.1 1 BSSMAP-LE RESET ACKNOWLEDGE message 

This message is sent in response to a Reset message to indicate that references and resources associated with LMU 
connections and location service transactions towards the entity sending the Reset have been released. The message 
may be sent from an SMLC to an MSC or BSC and from an MSC or BSC to an SMLC. 

This message is sent as a connectionless SCCP message. 

Table 9.11 : BSSMAP-LE RESET ACKNOWLEDGE message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 



1 Message format and information element coding 

This clause specifies the coding of the Information Elements used by the BSSAP-LE protocol. The spare bits in the 
coding of an IE shall be set to zero by the sender and shall be ignored by the receiver. 

All unassigned codes (whether omitted or explicitely Unassigned in the text) shall be treated as unknown (see clause 
'Error Handling and Future Compatibility'). 

The following conventions are assumed for the sequence of transmission of bits and bytes: 

Each bit position is marked as 1 to 8. Bit 1 is the least significant bit and is transmitted first. 

In an element octets are identified by number, octet 1 is transmitted first, then octet 2 etc. 

When a field extends over more than one octet, the order of bit values progressively decreases as the octet number 
increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet 
of the field. 

For variable length elements a length indicator is included, this indicates the number of octets following in the 
element. 

All fields within Information Elements are mandatory unless otherwise specified. The Information Element 
Identifier shall always be included. 

All spare bits are set to 0. 

For any information element of format TLV, the length indicator octet, as in 3GPP TS 08.08, defines the number of 
octets in the information element that follow the length indicator octet. 
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10.1 Message type 



Message type uniquely identifies the message being sent. It is a single octet element, mandatory in all messages. 
Table 10.1/3GPP TS 09.31 : Message type information element 



Category 



87654321 



Message Type 



00000000 Reserved. 



POSITIONING MESSAGES 



LMU CONTROL MESSAGES 



INFORMATION MESSAGES 



GENERAL MESSAGES 



00101011 
00101101 
00101110 

0000000 1 
00000010 

0000001 1 
000001 00 

00101010 
00111010 

00 110000 
0011000 1 



BSSMAP-LE PERFORM LOCATION REOUEST 
BSSMAP-LE PERFORM LOCATION RESPONSE 
BSSMAP-LE PERFORM LOCATION ABORT 

BSSMAP-LE LMU CONNECTION REOUEST 
BSSMAP-LE LMU CONNECTION ACCEPT 
BSSMAP-LE LMU CONNECTION REJECT 
BSSMAP-LE LMU CONNECTION RELEASE 

BSSMAP-LE CONNECTION ORIENTED INFORMATION 
BSSMAP-LE CONNECTIONLESS INFORMATION 

RESET 

RESET ACKNOWLEDGE 



10.2 Information Element Identifiers 

The next list shows the coding of the Information Element Identifiers used in the present document. 
Table 10.2/3GPP TS 09.31 : Information Element Identifier coding 



87654321 


Information element 


Reference 


00111110 


LCS QoS 


10.16 


01000011 


LCS Priority 


10.15 


01000100 


Location Type 


10.18 


01000101 


Geographic Location 


10.9 


01000110 


Positioning Data 


10.20 


01000111 


LCS Cause 


10.13 


01001000 


LCS Client Type 


10.14 


0100100 1 


APDU 


10.3 


010010 10 


Network Element Identity 


10.19 


010010 11 


GPS Assistance Data 


10.10 


01001100 


Decipliering Keys 


10.8 


01001101 


Return Error Request 


10.21 


01001110 


Return Error Cause 


10.22 


01001111 


Segmentation 


10.24 


000100 11 


Classmarl< Information Type 3 


10.7 


00000100 


Cause 


10.4 


00000101 


Cell Identifier 


10.5 


00 100001 


Chosen Channel 


10.6 


00000000 


IMSl 


10.11 


00000001 


ISDN Address 


10.12 


00000010 


Security 


10.23 


000000 1 1 


Signaling Point Code 


10.25 


00000100 


LMU Cause 


10.17 



10.3 APDU 

This is a variable length information element that conveys an embedded message or message segment associated with a 
higher level protocol. 
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8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2-3 


Length indicator 


Octet 4 


Spare Protocol ID 


Octet 5 

to 
Octet n 


The rest of the information element contains a message or 
message segment whose content and encoding are defined 
according to the protocol ID. 



Figure 10.3.1/3GPP TS 09.31 : APDU IE 



Length Indicator (octets 2-3). 

The most significant bit is bit 8 of Octet 2, and the least significant bit is bit 1 in Octet 3. The length indicator defines 
the total number of octets after length indicator. 

Protocol ID (bits 7-1 of octet 4) 

0000000 reserved 

0000001 BSSLAP 

0000010 LLP 

0000011 SMLCPP 
Embedded Message (octets 5-n). 



BSSLAP 



the embedded message is as defined in 3GPP TS 08.71 



LLP 



the embedded message contains a Facility Information Element as defined in 3GPP TS 04.71 
excluding the Facility lEI and length of Facility lEI octets defined in 3GPP TS 04.71 . 



SMLCPP 



the embedded message is as defined in 3GPP TS 08.31 



10.4 Cause 

This is a variable length information element indicating the reason for sending a Reset message. 



Octet 1 
Octet 2 
Octet 3 



8 7 6 


1 5 1 4 1 


3 1 2 1 1 1 


lEI 


Length indicator 


The rest of the information element is coded 
the Cause IE defined in 3GPP TS 08.08. 


as the value part of 



Figure 10.4.1/3GPP TS 09.31 : Cause IE 



10.5 Cell Identifier 



This is a variable length information element identifying a particular cell. 



Octet 1 
Octet 2 
Octet 3 



8 7 


6 


1 5 1 4 1 3 


1 2 1 1 1 


lEI 


Length indicator 


The rest of the information element is coded as 
the Cell Identifier IE defined in 3GPP TS 08.08. 


the value part of 



Figure 10.5.1/3GPP TS 09.31 : Cell Identifier IE 



10.6 Chosen Channel 

This information element identifiers a type of radio interface channel. 
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8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


The rest of the information element is coded as the value part of 
the Chosen Channel IE defined in 3GPP TS 08.08. 



Figure 10.6.1/3GPP TS 09.31 : Chosen Channel IE 



1 0.7 Classmark Information Type 3 



This information element contains classmark information for a target MS obtained from the MS Classmark 3 defined in 
3GPP TS 04.08. 



Octet 1 
Octet 2 
Octet 3 



8 



1 



lEI 



Length indicator 



The rest of the information element is coded as the value part of 
the Classmark Information Type 3 IE defined in 3GPP TS 08.08. 



Figure 10.7.1/3GPP TS 09.31 : Classmark Information Type 3 IE 



10.8 Deciphering Keys 



This information element defines the deciphering keys which should used by the MS to decode LCS broadcast 
assistance data. The parameter includes following data fields (All fields shall be included): 





8|7|6|5|4|3|2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


spare 


Ciphering 
Key Flag 


Octet 4 

to 
Octet 10 


Current Deciphering Key Value 


Octet 11 

to 
Octet 17 


Next Deciphering Key Value 



Figure 10.8.1/3GPP TS 09.31 : Deciphering Keys IE 

Ciphering Key Flag (octet 3) 

This flag indicates the current Ciphering Key Flag used in the LCS assistance data broadcast messages in the location 
area. 

Current Deciphering Key Value (octet 4 - 10) 

Current Deciphering Key contains the 56 bit deciphering key that is currently in use in location area for deciphering the 
LCS assistance data broadcast messages. 

Next Deciphering Key (octet 11 - 17) 

Next Deciphering Key contains the 56 bit deciphering key that will be used next in location area for deciphering the 
LCS assistance data broadcast messages. 



10.9 Geographic Location 



This is a variable length information element providing an estimate of a geographic location. 
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8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 

to 
Octet n 


The rest of the information element contains an octet sequence 
identical to that for the Ext-Geographicallnformation data type in 
3GPP TS 09.02. 



Figure 10.9.1/3GPP TS 09.31 : Geographic Location IE 



10.10 GPS Assistance Data 

This is a variable length information element identifying the GPS assistance data requested for an MS. 



Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


to 


Octet 8+2n 



8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


lEI 


Length indicator 


H 


G 


F 


E 


D 





B 


A 


P 





N 


M 


L 


K 


J 


1 


Satellite related data 



Figure 10.10.1/3GPP TS 09.31 : GPS Assistance Data IE 

Octet 3 

bit A Almanac 

: Almanac is not requested 
1 : Almanac is requested 

bitB UTC Model 

: UTC Model is not requested 
1 : UTC Model is requested 

bit C Ionospheric Model 

: Ionospheric Model is not requested 
1 : Ionospheric Model is requested 

bit D Navigation Model 

: Navigation Model is not requested - octets 5 to 8+2n are not present 
1 : Navigation Model is requested - octets 5 to 8+2n are present 

bit E DGPS Corrections 

: DGPS Corrections are not requested 
1 : DGPS Corrections are requested 

bit F Reference Location 

: Reference Location is not requested 
1 : Reference Location is requested 

bit G Reference Time 

: Reference Time is not requested 
1 : Reference Time is requested 

bit H Acquisition Assistance 

0: Acquisition Assistance is not requested 

1 : Acquisition Assistance is requested 

bit I Real-Time Integrity 

0: Real-Time Integrity is not requested 

1 : Real-Time Integrity is requested 
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bits J through P are Spare bits 



At least one of bits A, B, C, D, E, F, G, H or I, shall be set to the value "1". 





8 


7 


6 


5 


4 


3 


2 


1 




















Octet 5 


GPS Week 


Spare 


Octet 6 


GPS Weekl 
NSAT 
Spare 


Octet 7 


GPS Toe 


Octet 8 


NSAT 




T-Toe limit 




Octet 9 


spare 


SatID 1 




Octet 10 


I0DE1 






Octet 7+2n 


spare 


SatID n 




Octet 8+2n 


lODEn 



Figure 10.10.2/3GPP TS 09.31 : Coding of Satellite Related Data 

GPS Week (bits 7-8 octet 5 and octet 6) 

This field contains a 10 bit binary representation of the GPS Week of the assistance currently held by the MS. The most 
significant bit of the GPS Week is bit 8 in octet 5 and the least significant bit is bit 1 in octet 6. 

GPS_Toe (octet 7) 

This field contains a binary representation of the GPS time of ephemeris in hours of the newest ephemeris set contained 
in handset memory (range 0-167). 

NSAT (octet 8, bits 5-8) 

This field contains a binary representation of the number of satellites to be considered for the current GPS assistance 
request. If the MS has no ephemeris data, this field shall be set to zero. If the MS has ephemeris data whose age exceeds 
the T-Toe limit, this field may be set to zero. If the SMLC receives a zero value for this field, it shall ignore the GPS 
Week and GPS_Toe fields and assume that the MS has no ephemeris data. 

T-Toe limit (octet 8, bits 1-4) 

This field contains a binary representation of the ephemeris age tolerance of the MS to the network in hours (range 0- 
10). 

SatID X (x = 1,2, ... n) (octet 7 + 2x, bits 1-6) 

This field is present only if NSAT exceeds zero and contains a binary representation of the identity of a satellite for 
which the assistance request is applicable. The number of satellite fields is indicated in the field NSAT. 

lODE X (x = 1,2, ... n) (octet 8 + 2x) 

This field is present only if NSAT exceeds zero and contains a binary representation of the Issue of Data Ephemeris 
held in the MS, which identifies the sequence number for the satellite x (x = 1, 2, ..., n). The SMLC shall derive the 
issue date and time for the lODE of each satellite x from the GPS Week and GPS_Toe fields (e.g. when a particular 
lODE value for a satellite x was issued more than once within the period of T-Toe limit). 
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10.11 IMSI 

The IMSI is of variable length and is coded as a sequence of BCD digits, compressed two into each octet. This is a 
variable length element, and includes a length indicator. The IMSI is defined in 3GPP TS 03.03. It shall not exceed 15 
digits (see 3GPP TS 03.03). 





8 7 6 


1 5 1 4 


3 1 2 


1 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


llVISIdigitI 


odd/ 
even 











Octet 4 


IMSI digit 3 


IMSI digit 2 


Octet 4+x 


IMSI digit i+1 


IMSI digit i 



Figure 10.11. 1/3GPP TS 09.31 : IMSI IE 

Where x = (i-2)/2 and i is always even 

* The value of the odd/even bit (bit 4 in octect 3) indicates: 

Even number of IMSI digits 

1 Odd number of IMSI digits 

If the number of IMSI digits is even then bits 5 to 8 of the last octet shall be filled with an end mark 
coded as 1111. 



10.12 ISDN Address 



This information element contains an ISDN address. 



Octet 1 
Octet 2 
Octet 3 



lEI 



Length indicator 



The rest of the information element contains an octet string coded 
the same as the ISDN-AddressString common data type defined in 
3GPP TS 09.02 



Figure 10.12.1/3GPP TS 09.31 : ISDN Address IE 



10.13 LCS Cause 

The LCS Cause parameter is of variable length IE and provides the reason for an unsuccessful location request. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 



8 



1 



lEI 



Length indicator 



Cause value 



Diagnostic value (NOTE 1) 



NOTE 1 : The inclusion of this octet depends on the cause value. 

Figure 10.13.1/3GPP TS 09.31 : LCS Cause IE 
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Table 10.13.1/3GPP TS 09.31 : Cause value 



LCS Cause value (octet 3) 


Bits 




87654321 




00000000 


Unspecified 


00000001 


System Failure 


00000010 


Protocol Error 


0000001 1 


Data missing in position request 


00000100 


Unexpected data value in position request 


00000101 


Position method failure 


000001 10 


Target MS Unreachable 


000001 1 1 


Location request aborted 


00001000 


Facility not supported 


00001001 


Inter-BSC Handover Ongoing 


00001010 


Intra-BSC Handover Complete 


0000101 1 


Congestion 


00001 100 




to unspecified in this version of the protocol 


11111111 





Diagnostic value (octet 4): 

this octet may be included if the cause value indicates "position method failure", the binary encoding of this octet 
shall encode the same set of values as defined for the PositionMethodFailure-Diagnostic in 3GPP TS 09.02. 
Values outside those defined in 3GPP TS 09.02 shall be ignored by a receiver. 



10.14 LCS Client Type 

This information element identifies the type of LCS Client. 



8 


|7|6|5|4|3|2| 


1 1 


lEI 


Length indicator 


Client Category Client Subtype 



Octet 1 
Octet 2 
Octet 3 



Figure 10.14.1/3GPP TS 09.31 : LCS Client Type IE 

The client category (bits 8-5 of octet 3) and the client subtype (bits 4-1 of octet 3) are coded as follows. 



Client Category 


Client Subtype 


Explanation 


0000 


0000 
all values 


Value Added Client 

unspecified 

reserved 


0010 


0000 
0001 
0010 
0011 
0100 
other values 


PLMN operator 

unspecified 

broadcast service 

O&M 

anonymous statistics 

Target MS service support 

reserved 


0011 


0000 
other values 


Emergency services 

unspecified 

reserved 


0100 


0000 
other values 


Lawful Intercept services 

unspecified 

reserved 


0101 -1111 


all values 


reserved 
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10.15 LCS Priority 



This information element defines the priority level of a location request. 



Octet 1 
Octet 2 
Octet 3 



8 


7 1 6 


1 5 1 4 1 3 


1 2 1 1 1 


lEI 


Length indicator 


This octet is coded as 


the LCS-Priority octet in 


3GPP TS 09.02. 



Figure 10.15.1/3GPP TS 09.31 : LCS Priority IE 



10.16 LCSQoS 

This information element defines the Quality of Service for a location request. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 
Octet 5 
Octet 6 



8 7 


6 


1 5 1 4 1 3 1 


2 


1 1 1 


lEI 


Length indicator 






spare 




1 VERT 1 


HA 


Horizontal Accuracy 


VA 


Vertical Accuracy 


RT 




spare 







Figure 10.16.1/3GPP TS 09.31 : LCS QoS IE 



Octet 3 



VERT = vertical coordinate indicator 

: vertical coordinate not requested 

1 : vertical coordinate is requested 

Octet 4 

bit 8 HA = horizontal accuracy indicator 

: Horizontal Accuracy is not specified 

1 : Horizontal Accuracy is specified 

bits 7-1 Horizontal Accuracy : 

spare (set all zeroes) if HA=0 

set to 7 bit uncertainty code in 3GPP TS 03.32 if HA=1 

Octet 5 - applicable only if VERT = 1 

bit 8 VA = vertical accuracy indicator 

: Vertical Accuracy is not specified 

1 : Vertical Accuracy is specified 

bits 7-1 Vertical Accuracy : 

spare (set all zeroes) if VA=0 

set to 7 bit uncertainty altitude code in 3GPP TS 03.32 if VA=1 



Octet 6 



bits 8-7 RT = response time category 

00 : Response Time is not specified 

01 : Low Delay 

10 : Delay Tolerant 

1 1 : reserved 

bits 6-1 spare 
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10.17 LMU Cause 



The LMU Cause parameter provides the reason for the release or rejection of an LMU signaling connection between an 
MSC and SMLC. 



Octet 1 
Octet 2 
Octet 3 



8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


lEI 


Length indicator 


Cause value 



Figure 10.17.1/3GPP TS 09.31 : LMU Cause IE 



Table 10.17.1/3GPP TS 09.31 : Cause value 



Cause value (octet 3) 


Bits 




87654321 




00000000 


Unspecified 


00000001 


Normal Release 


00000010 


System Failure 


0000001 1 


Protocol Error 


00000100 


Missing Data 


00000101 


Unexpected Data 


000001 10 


Congestion 


000001 1 1 


Loss of radio channel to LMU 


00001000 


Release by LMU 


00001001 


Unknown LMU 


00001010 


LMU signaling error 


000010 1 1 


LMU not authenticated 


00001 100 


No response from LMU 


00001 1 01 


LMU in erroneous state 


00001 1 10 




to 


unspecified in this version of the protocol 


11111111 





10.18 Location Type 

This is a variable length information element defining the type of location information being requested. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 



IE! 



Length indicator 



Location Information 



Positioning IVIethod 



Figure 10.18.1/3GPP TS 09.31 : Location Type IE 

Coding of location information (octet 3): 

00000000 current geographic location 

00000001 location assistance information for the target MS 

00000010 deciphering keys for broadcast assistance data for the target MS 
all other values are reserved. 
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Positioning Method (octet 4). 

This octet shall be included if the location information in octet 3 indicates "location assistance information for the target 
MS" or "deciphering keys for broadcast assistance data for the target MS" and shall be omitted otherwise. 

00000000 reserved 

0000000 1 Mobile Assisted E-OTD 

00000010 Mobile Based E-OTD 

00000011 Assisted GPS 
all other values are reserved. 



10.19 Network Element Identity 



This is a variable length information element identifying a network element, by association with either a designated cell 
site or a designated location area. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 

to 
Octet n 



8 



1 



lEI 



Length indicator 



spare 



Identity Discrminator 



Networl< Element Identification 



Figure 10.19.1/3GPP TS 09.31 : Network Element Identity IE 

Identity Discriminator (bits 4-1 of octet 3) 

0000 Identification using the MCC + MNC H-LAC + CI as defined in 3GPP TS 03.03 

0001 Identification using LAC + CI as defined in 3GPP TS 03.03 

0100 Identification using the MCC + MNC + LAC as defined in 3GPP TS 03.03 

0101 Identification using the LAC as defined in 3GPP TS 03.03 
All other values are reserved. 



Octet 4 

to 
Octet 10 

Figure 10.19.2/3GPP TS 09.31 : Coding of Network Element Identification using the 

MCC+MNC+LAC+CI 

Octets 4 to 10 are coded as the Cell Identification of the Cell Identifier IE for Cell identification discriminator = 0000 
defined in 3GPP TS 08.08. 



8 


7 


6 1 5 1 4 1 3 


2 


1 1 


MCC+MNC+LAC+CI 





8 


7 


6 


5 1 4 


3 


2 


1 


Octet 4 

to 
Octet 7 


LAC + CI 



Figure 10.19.3/3GPP TS 09.31 : Coding of Network Element Identification using the LAC + CI 

Octets 4 to 7 are coded as the Cell Identification of the Cell Identifier IE for Cell identification discriminator = 0001 
defined in 3GPP TS 08.08. 
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8 


7 


6 


5 4 


3 


2 


1 


Octet 4 

to 
Octet 6 


MCC+ MNC 


Octet 7 

to 
Octet 8 


LAC 



Figure 10.19.4/3GPP TS 09.31 : Coding of Network Element Identification using the MCC + MNC + LAC 

Octets 4 to 8 are coded as the corresponding octets in the Cell Identification of the Cell Identifier List IE for Cell 
identification discriminator = 0100 defined in 3GPP TS 08.08. 

Octet 4 
Octet 5 

Figure 10.19.5/3GPP TS 09.31 : Coding of Network Element Identification using the LAC 

Octets 4 to 5 are coded as the corresponding octets in the Cell Identification of the Cell Identifier List IE for Cell 
identification discriminator = 0101 defined in 3GPP TS 08.08. 



8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


LAC 


LAC - continued 



10.20 Positioning Data 



This is a variable length information element providing positioning data associated with a successful or unsuccessful 
locatiomn attempt for a target MS. 



Octet 1 

Octet 2 

Octet 3 

Octets 4-4+m 

Octets ..-4+nm 



8 



1 



lEI 



Length indicator 



spare 



Positioning Data Discriminator 



Positioning IVIethod 1 



Positioning IVIethod n 



Figure 10.20.1/3GPP TS 09.31 : Positioning Data IE 

The positioning data discrminator (bits 4-1 of octet 3) defines the type of data provided for each positioning method: 
0000 indicate usage of each positioning method that was attempted either successfully or unsuccessfully 
all other values are reserved 
Coding of the postioning method octets for positioning data discrminator = 0: 

Octet X I positioning metiiod | usage | 
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Coding of positioning method (bits 8-4): 

00000 Timing Advance 

00001 TOA 

00010 AOA 

00011 Mobile Assisted E-OTD 

00100 Mobile Based E-OTD 

00101 Mobile Assisted GPS 

001 10 Mobile Based GPS 

00111 Conventional GPS 
01000 

to reserved for GSM 

01111 

10000 

to reserved for network specific positioning methods 

11111 

Coding of usage (bits 3-1) 

000 Attempted unsuccessfully due to failure or interruption 

001 Attempted successfully: results not used to generate location 

010 Attempted successfully: results used to verify but not generate location 

01 1 Attempted successfully: results used to generate location 

100 Attempted successfully: case where MS supports multiple mobile based positioning methods 
and the actual method or methods used by the MS cannot be determined 



10.21 Return Error Request 



8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


lEI 


Length indicator 


Return Error Type 



The Return Error Request parameter indicates a request from the source of a BSSMAP-LE connectionless information 
message for an error response if the message cannot be delivered to its final destination. 

Octet 1 
Octet 2 
Octet 3 

Figure 10.21.1/3GPP TS 09.31: Return Error Request IE 

Coding of Return Error Type (octet 3): 

00000000 Return an unsegmented APDU or the first segment of a segmented APDU; no Return Error shall 

be sent if no APDU was received or if a subsequent segment of a segmented APDU was received. 

00000001 

to Reserved for future use. 

11111111 

1 0.22 Return Error Cause 

The Return Error Cause parameter provides the reason for unsuccessful delivery of a BSSMAP-LE Connectionless 
Information message to its final destination. 

Octet 1 
Octet 2 
Octet 3 

Figure 10.22. 1/3GPP TS 09.31 : Return Error Cause IE 



8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


lEI 


Lengtii indicator 


Cause value 



£75/ 



3GPP TS 09.31 version 7.8.0 Release 1998 



45 



ETSI TS 101 530 V7.8.0 (2004-05) 



Table 10.22.1/3GPP TS 09.31 : Cause value 



Cause value (octet 3) 


Bits 




87654321 




00000000 


Unspecified 


00000001 


System Failure 


00000010 


Protocol Error 


0000001 1 


Destination unknown 


00000100 


Destination unreachable 


00000101 


Congestion 


000001 10 




to unspecified in this version of the protocol 


11111111 





10.23 Security 



This information element defines what security measures are needed for signaling to an LMU. 



Octet 1 
Octet 2 
Octet 3 



8 


7 


6 1 5 1 4 1 


3 


1 2 


1 1 


lEI 


Length indicator 






spare 




CIPH 


AUTH 



Figure 10.23.1/3GPP TS 09.31 : Security IE 



Coding of octet 3: 



bit 1 AUTH = authentication indicator 

: authentication of LMU not required 

1 : authentication of LMU required 

bit 2 CIPH = ciphering indicator 

: ciphering of LMU signaling data not required 

1 : ciphering of LMU signaling data required 



10.24 Segmentation 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 1 


lEI 


Length indicator 


Segmentation and IVIessage Information 



This is a variable length information element that carries information for a segmented APDU. 

Octet 1 

Octet 2 

Octets 3-n 

Figure 10.24.1/3GPP TS 09.31 : Segmentation IE 

There are two options for the coding of the Segmentation and Message Information portion; 1 octet containing 
segmentation information only and 3 octets containing segmentation and message information. 

Encoding of Segmentation Information: 



Octet 3 



Figure 10.24.2/3GPP TS 09.31 : Segmentation Information 



8 7 6 


5 


4 3 2 1 


Spare 


S 


Segment Number 
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Encoding of Segmentation and Message Information: 





8 


1 7 1 


6 


5 


4 3 2 


1 1 


Octet 3 


Spare 


S 


Segment Number 


Octet 4-5 


Message ID 



Figure 10.24.3/3GPP TS 09.31: Segmentation and IVIessage Information 

S (Segmentation Bit, bit 5 of octet 3) 

final segment of a segmented message 

1 non-final segment of a segmented message 

Segment Number (bits 4-1 of octet 3) 

This field contains a 4 bit binary representation of the segment number. The first segment has the value '0000', the next 
'000 r, and so on. 

Message ID (octets 4 and 5) 

This field contains a 16 bit binary representation of the message identity, i.e. values 0-65535 are possible. 

This field is used to identify to which messages different segments belong to. 



1 0.25 Signaling Point Code 



8 


7 


6 1 5 1 4 1 3 


2 


1 1 


lEI 


Length indicator 


Signaling Point Code value 



This is a variable length information element providing that provides the signaling point code of a network element. 

Octet 1 

Octet 2 

Octets 3-n 

Figure 10.25.1/3GPP TS 09.31 : Signaling Point Code IE 

There are three options for the coding of Signaling Point Code value; 2 octets containing a 14 bit ITU code, 3 octets 
containing a 24 bit unstructured code and 3 octets containing a 24 bit ANSI structured code. 

Encoding of 14 bit ITU signaling point code: 



Octet 3 
Octets 4 







signaling point code (high order bits) 



signaling point code (low order bits) 



Encoding of a 24 bit unstructured signaling point code: 



Octet 3 
Octet 4 
Octets 5 



signaling point code (high order octet) 



signaling point (second octet) 



signaling point code (low order octet) 



Encoding of a 24 bit ANSI structured signaling point code: 



Octet 3 
Octet 4 
Octets 5 



Network Identifier 



Network Cluster 



Network Cluster Member 
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Annex A (informative): 
Change history 



Meeting# 


CR 


Rev 


Subject/Comment 


New 


SMG#30bis 


- 




Approved at SMG#30bis as Release 98 


7.0.0 


SMG#31 


A001 


3 


Addition of further LOS functionality in GSIVI Release 98 


7.1.0 


SMG#31 


A002 


1 


Provision of Segmentation support for LCS 


7.1.0 


SMG#31bis 


A003 


1 


Addition of Integrity Monitor Status 


7.2.0 


SMG#31bis 


A004 


1 


Addition of missing "LMU Cause" IE 


7.2.0 


SMG#31bis 


A005 


1 


Correction of IVIessage Type Encoding and GPS Assistance Data IE 


7.2.0 


SMG#31bis 


A006 




Addition of Global reset and SCCP error procedures 


7.2.0 


smg#32 


A015 




Error handling in case requested position method is not supported 


7.3.0 


GP-01 


A017 


1 


Geographic Shape restriction in LCS 


7.4.0 


GP-01 


- 




GSIVI xx.xx references changed to 3GPP TS xx.xx. Format changed to 3GPP 
style. 


7.4.0 


GP-02 


A024 




Correction of Location Type IE length in BSSMAP-LE PERFORIVI LOCATION 
REOUEST message {R98) 


7.5.0 


GP-07 


A028 


1 


Define number of keys in Deciphering Keys IE 


7.6.0 


GP-07 


A026 




Define lE's order of appearance in BSSAP-LE message 


7.6.0 


GP-10 


A030 


1 


Clarify Requested GPS Assistance Data IE 


7.7.0 


GP-19 


A033 


2 


Correction of behaviour of the Location Request procedure 


7.8.0 
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